Skip to content

✨ Add support for parsing and persisting explicit pkg.Release field#2543

Open
rashmigottipati wants to merge 2 commits intooperator-framework:mainfrom
rashmigottipati:oprun-4277-implementation
Open

✨ Add support for parsing and persisting explicit pkg.Release field#2543
rashmigottipati wants to merge 2 commits intooperator-framework:mainfrom
rashmigottipati:oprun-4277-implementation

Conversation

@rashmigottipati
Copy link
Copy Markdown
Member

@rashmigottipati rashmigottipati commented Mar 6, 2026

Description

Summary

Adds support for parsing the explicit pkg.Release field from bundle metadata and persisting it through cluster storage (roundtripping). This is gated by the new BundleReleaseSupport alpha feature gate (disabled by default).

Changes

  • Added BundleReleaseSupport alpha feature gate (disabled by default)
  • Added Release field to BundleMetadata CRD type
  • Added BundleReleaseKey label constant for annotation storage
  • Updated bundleutil.parseVersionRelease() to: Parse explicit pkg.Release when feature gate enabled and field present. Fall back to legacy registry+v1 behavior (release in build metadata) otherwise
  • Updated bundleutil.MetadataFor() to serialize release value from VersionRelease
  • Added roundtripping support: store release in CRD field and annotations, read it back in filters and controllers

Feature Gate Behavior

When enabled:

  • Bundles with explicit pkg.Release field: release parsed separately, build metadata preserved for proper semver purpose
  • Bundles without explicit release: falls back to registry+v1 parsing (release from build metadata)

When feature gate disabled:

  • All bundles use registry+v1 parsing (release from build metadata)
  • Explicit pkg.Release field ignored

Reviewer Checklist

  • API Go Documentation
  • Tests: Unit Tests
  • Comprehensive Commit Messages
  • Links to related GitHub Issue(s)

Link to Github Issue: #2495
Epic: #2479

Copilot AI review requested due to automatic review settings March 6, 2026 16:37
@openshift-ci openshift-ci bot requested review from joelanford and perdasilva March 6, 2026 16:37
@netlify
Copy link
Copy Markdown

netlify bot commented Mar 6, 2026

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit d13ce71
🔍 Latest deploy log https://app.netlify.com/projects/olmv1/deploys/69d9af41e723eb000876cf17
😎 Deploy Preview https://deploy-preview-2543--olmv1.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@openshift-ci
Copy link
Copy Markdown

openshift-ci bot commented Mar 6, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kevinrizza for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR introduces an alpha feature gate to allow OLMv1 upgrade resolution to treat “re-released” bundles (same semver, higher release/build value like 2.0.0+1 -> 2.0.0+2) as valid successors when explicitly enabled.

Changes:

  • Added ReleaseVersionPriority feature gate (Alpha, default disabled).
  • Added SameVersionHigherRelease() predicate and integrated it into SuccessorsOf() behind the feature gate.
  • Added unit tests for SameVersionHigherRelease() and for SuccessorsOf() with the gate disabled.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
internal/operator-controller/features/features.go Defines the new ReleaseVersionPriority feature gate and its spec.
internal/operator-controller/catalogmetadata/filter/successors.go Conditionally expands successor matching to include same-version/higher-release bundles when gated on.
internal/operator-controller/catalogmetadata/filter/bundle_predicates.go Adds the SameVersionHigherRelease() predicate.
internal/operator-controller/catalogmetadata/filter/bundle_predicates_test.go Adds predicate unit tests including edge cases.
internal/operator-controller/catalogmetadata/filter/successors_test.go Adds a regression test to ensure default (gate-off) behavior does not accept higher-release bundles.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@codecov
Copy link
Copy Markdown

codecov bot commented Mar 6, 2026

Codecov Report

❌ Patch coverage is 75.00000% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.96%. Comparing base (b6dfd40) to head (d13ce71).
⚠️ Report is 4 commits behind head on main.

Files with missing lines Patch % Lines
...ernal/operator-controller/bundle/versionrelease.go 0.00% 7 Missing ⚠️
...or-controller/catalogmetadata/filter/successors.go 62.50% 3 Missing and 3 partials ⚠️
applyconfigurations/api/v1/bundlemetadata.go 0.00% 3 Missing ⚠️
internal/operator-controller/bundleutil/bundle.go 92.59% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2543      +/-   ##
==========================================
+ Coverage   68.91%   68.96%   +0.05%     
==========================================
  Files         139      140       +1     
  Lines        9863     9961      +98     
==========================================
+ Hits         6797     6870      +73     
- Misses       2559     2575      +16     
- Partials      507      516       +9     
Flag Coverage Δ
e2e 37.46% <36.11%> (-0.21%) ⬇️
experimental-e2e 52.20% <41.66%> (-0.10%) ⬇️
unit 53.63% <58.33%> (+0.09%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copilot AI review requested due to automatic review settings March 6, 2026 17:34
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@joelanford
Copy link
Copy Markdown
Member

If I understand this correctly, it looks like this introduces the new behavior that an explicit upgrade edge doesn't actually have to exist in the catalog to upgrade to a bundle that has the same version and a higher release. Is that the intent? (If so let's make that clear in the PR description).

Is it also the intent that we'll inherit the upgrade edges of the first release of the version?

@grokspawn
Copy link
Copy Markdown
Contributor

grokspawn commented Mar 9, 2026

We discussed earlier today. I think the first step is to essentially revert #2273 so that we're not attempting to interpret build metadata as release info anymore. Any catalogs built with tooling that supports release versioning will automagically propagate the build metadata into the CSV's spec.release field anyway, so regardless of whether the operator author used the old build metadata approach or the new spec.release approach, they would still have spec.release here.

The next step is to ensure that we're sorting successors using the CompositeVersion, which is easily performed if using the Bundle comparator during the sort.

This will prefer version+release over version.

#2273 makes the claim that future bundle types will drop this approach, not that registry+v1 bundles should. So that's my bad.
From the perspective of fulfilling handling precedents for registry+v1 bundles, we need to retain the ability to differentiate/order them by build metadata. :(

@grokspawn
Copy link
Copy Markdown
Contributor

If I understand this correctly, it looks like this introduces the new behavior that an explicit upgrade edge doesn't actually have to exist in the catalog to upgrade to a bundle that has the same version and a higher release. Is that the intent? (If so let's make that clear in the PR description).

Is it also the intent that we'll inherit the upgrade edges of the first release of the version?

Sadly, we have to rely on the presence of existing graph edges or we break assumptions users have with the registry+v1 bundle format, coming from v0.

So even though we have the ability to prefer version+release over version, since replaces/skips use named bundles instead of bundle versions we have to support the older behavior.

@joelanford
Copy link
Copy Markdown
Member

I think the first step is to essentially revert #2273 so that we're not attempting to interpret build metadata as release info anymore.

That would be a regression of a bug fix that #2273 made though, right?

Sadly, we have to rely on the presence of existing graph edges or we break assumptions users have with the registry+v1 bundle format, coming from v0.

So even though we have the ability to prefer version+release over version, since replaces/skips use named bundles instead of bundle versions we have to support the older behavior.

Yeah, agreed. I reached the same conclusion after thinking about this more.

So if I understand correctly now:

  1. The existing code on main already honors the upgrade graph and orders "same version, different release" correctly when parsing from build metadata
  2. The existing code on main knows nothing about the new release field.

So the change we need now is "look for release in the olm.package property, and if present, prefer it over build metadata"?

Copilot AI review requested due to automatic review settings March 12, 2026 19:55
@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from 5681488 to 8dcab49 Compare March 12, 2026 20:00
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@grokspawn
Copy link
Copy Markdown
Contributor

Adjusted my comments. I missed the part of the #2273 description when it said that we wouldn't divert from semver ordering for any new bundle formats.
From the perspective of registry+v1 bundles, this is precedent and we should support the new case with .spec.release is available, otherwise falling back on the 'is it bundle metadata' ordering logic.

@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from a2e5062 to 1e9cded Compare April 2, 2026 20:52
Copilot AI review requested due to automatic review settings April 2, 2026 20:52
@rashmigottipati rashmigottipati changed the title ✨ Support explicit pkg.Release field with build metadata fallback for bundle comparison ✨ Add support for parsing and persisting explicit pkg.Release field Apr 9, 2026
@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from 8d6dda3 to d7d824c Compare April 9, 2026 20:45
@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from d7d824c to aa0a0dc Compare April 9, 2026 21:00
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated 5 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from aa0a0dc to 0ba7072 Compare April 9, 2026 21:26
Copilot AI review requested due to automatic review settings April 9, 2026 21:34
@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from 0ba7072 to 630c47f Compare April 9, 2026 21:34
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated 1 comment.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Signed-off-by: Rashmi Gottipati <rgottipa@redhat.com>
@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from 630c47f to 4519cc6 Compare April 10, 2026 03:06
Copilot AI review requested due to automatic review settings April 11, 2026 01:56
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Version: vr.Version.String(),
}
relStr := vr.Release.String()
bm.Release = &relStr
Comment on lines +411 to 421
releaseValue := ""
if state.resolvedRevisionMetadata.Release != nil {
releaseValue = *state.resolvedRevisionMetadata.Release
}
revisionAnnotations := map[string]string{
labels.BundleNameKey: state.resolvedRevisionMetadata.Name,
labels.PackageNameKey: state.resolvedRevisionMetadata.Package,
labels.BundleVersionKey: state.resolvedRevisionMetadata.Version,
labels.BundleReferenceKey: state.resolvedRevisionMetadata.Image,
labels.BundleReleaseKey: releaseValue,
}
Comment on lines +106 to 116
releaseValue := ""
if state.resolvedRevisionMetadata.Release != nil {
releaseValue = *state.resolvedRevisionMetadata.Release
}
revisionAnnotations := map[string]string{
labels.BundleNameKey: state.resolvedRevisionMetadata.Name,
labels.PackageNameKey: state.resolvedRevisionMetadata.Package,
labels.BundleVersionKey: state.resolvedRevisionMetadata.Version,
labels.BundleReferenceKey: state.resolvedRevisionMetadata.Image,
labels.BundleReleaseKey: releaseValue,
}
Comment on lines +228 to +229
require.NotNil(t, result.Release)
require.Empty(t, *result.Release)
@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from a833002 to 3b933d4 Compare April 11, 2026 02:12
Signed-off-by: Rashmi Gottipati <rgottipa@redhat.com>
Copilot AI review requested due to automatic review settings April 11, 2026 02:17
@rashmigottipati rashmigottipati force-pushed the oprun-4277-implementation branch from 3b933d4 to d13ce71 Compare April 11, 2026 02:17
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +411 to 421
releaseValue := ""
if state.resolvedRevisionMetadata.Release != nil {
releaseValue = *state.resolvedRevisionMetadata.Release
}
revisionAnnotations := map[string]string{
labels.BundleNameKey: state.resolvedRevisionMetadata.Name,
labels.PackageNameKey: state.resolvedRevisionMetadata.Package,
labels.BundleVersionKey: state.resolvedRevisionMetadata.Version,
labels.BundleReferenceKey: state.resolvedRevisionMetadata.Image,
labels.BundleReleaseKey: releaseValue,
}
Comment on lines +106 to 116
releaseValue := ""
if state.resolvedRevisionMetadata.Release != nil {
releaseValue = *state.resolvedRevisionMetadata.Release
}
revisionAnnotations := map[string]string{
labels.BundleNameKey: state.resolvedRevisionMetadata.Name,
labels.PackageNameKey: state.resolvedRevisionMetadata.Package,
labels.BundleVersionKey: state.resolvedRevisionMetadata.Version,
labels.BundleReferenceKey: state.resolvedRevisionMetadata.Image,
labels.BundleReleaseKey: releaseValue,
}
Comment on lines +26 to +50
func parseVersionRelease(pkgData json.RawMessage) (*bundle.VersionRelease, error) {
var pkg property.Package
if err := json.Unmarshal(pkgData, &pkg); err != nil {
return nil, fmt.Errorf("error unmarshalling package property: %w", err)
}

// When BundleReleaseSupport is enabled and bundle has explicit release field, use it.
// Note: Build metadata is preserved here because with an explicit release field,
// build metadata serves its proper semver purpose (e.g., git commit, build number).
// In contrast, NewLegacyRegistryV1VersionRelease clears build metadata because it
// interprets build metadata AS the release value for registry+v1 bundles.
if features.OperatorControllerFeatureGate.Enabled(features.BundleReleaseSupport) && pkg.Release != "" {
vers, err := bsemver.Parse(pkg.Version)
if err != nil {
return nil, fmt.Errorf("error parsing version %q: %w", pkg.Version, err)
}
rel, err := bundle.NewRelease(pkg.Release)
if err != nil {
return nil, fmt.Errorf("error parsing release %q: %w", pkg.Release, err)
}
return &bundle.VersionRelease{
Version: vers,
Release: rel,
}, nil
}
Comment on lines +110 to +154
tests := []struct {
name string
pkgProperty *property.Property
wantVersionRelease *bundle.VersionRelease
wantErr bool
}{
{
name: "explicit release field - takes precedence over build metadata",
pkgProperty: &property.Property{
Type: property.TypePackage,
Value: json.RawMessage(`{"version": "1.0.0+ignored", "release": "2"}`),
},
wantVersionRelease: &bundle.VersionRelease{
Version: bsemver.MustParse("1.0.0+ignored"), // Build metadata preserved - serves its proper semver purpose
Release: bundle.Release([]bsemver.PRVersion{
{VersionNum: 2, IsNum: true},
}),
},
wantErr: false,
},
{
name: "explicit release field - complex release",
pkgProperty: &property.Property{
Type: property.TypePackage,
Value: json.RawMessage(`{"version": "2.1.0", "release": "1.alpha.3"}`),
},
wantVersionRelease: &bundle.VersionRelease{
Version: bsemver.MustParse("2.1.0"),
Release: bundle.Release([]bsemver.PRVersion{
{VersionNum: 1, IsNum: true},
{VersionStr: "alpha"},
{VersionNum: 3, IsNum: true},
}),
},
wantErr: false,
},
{
name: "explicit release field - invalid release",
pkgProperty: &property.Property{
Type: property.TypePackage,
Value: json.RawMessage(`{"version": "1.0.0", "release": "001"}`),
},
wantErr: true,
},
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants